This Technical Note answers a common question about MPW C++: “Why doesn’t HandleObject support multiple inheritance?” It does this by giving a brief overview of how multiple inheritance is implemented in MPW C++.
What Are HandleObjects Anyway?
MPW C++ contains several extensions to “standard C++” for supporting Macintosh programming. One such extension is the built-in class HandleObject. An instance of any class descended from HandleObject is allocated as a handle in the heap. You refer to one of these instances as if it were a simple pointer; the compiler takes care of the extra dereference required because the object is really a handle.
A HandleObject is useful in Macintosh programming for the same reason a handle is useful. The use of handles helps prevent heap fragmentation. The nature of HandleObject imposes some restrictions on how you can use it in a program, however.
First, since each instance is allocated as a handle, it follows that all instances must be allocated on the heap. (“Native” C++ objects can be allocated on the stack or in the global space as well.) Consequently, you always declare variables, parameters, etc. to be pointers to the class. For example:
class TSample: public HandleObject {
public:
…
long fData;
};
TSample *aSampleInstance; // Legal
TSample anotherSample; // Results in a compile-time error
The error message the compiler generates in this case is “Can’t declare a handle/pascal object: anotherSample.” At first this message might seem strange, because the last two lines in this code seem to both declare objects. Actually, the first declaration is of a pointer to an object, not of the object itself.
The second restriction is that you must follow the usual rules for manipulating handles. In particular, you have to be careful about creating pointers to a HandleObject instance variable, since the object might move if the heap is compacted. If you write
long *x = & (aSampleInstance -> fData);
then x becomes invalid if the object moves. The solution in this case is to lock the object if there’s a possibility of the heap being compacted. Instances of HandleObject are allocated with a call to _NewHandle, so you can use _HLock and _HUnlock to lock and unlock the object.
The third restriction is that you cannot use multiple inheritance with a HandleObject. The reason behind this restriction is not evident, however. To understand the reason, you must look at the implementation of multiple inheritance.
Implementing Multiple Inheritance
To understand how multiple inheritance is implemented, one needs a simple example. Suppose you define two classes as follows:
class TBaseA {
public:
virtual void SetVarA(long newValue);
long fVarA;
…
};
class TBaseB {
public:
virtual void SetVarB(long newValue);
long fVarB;
…
};
If you were to look at instances of these classes (see Figure 1), you would find that in each case the instance storage would contain four bytes for the C++ virtual table (vtable) and four bytes for the instance variable. Any code that accesses the instance variable (for example TBaseB::SetVarB) would do so using a fixed offset from the start of the object. (In this particular version of C++, this offset was 0; your offset may vary.)
Figure 1–Layout of TBaseA and TBaseB Instances
Now suppose you define another class:
class TDerived: public TBaseA, public TBaseB {
public:
virtual void SetDerivedVar(long newValue);
long fDerivedVar;
…
};
In this case, an instance of TDerived has the following layout:
Figure 2–Layout of TDerived Instance
This is what you would expect. TDerived inherits from both TBaseA and TBaseB, and therefore instances of TDerived contain a part that is a TBaseA and a part that is a TBaseB. In addition, the virtual table vtableDerived includes the tables for both TBaseA and TDerived.
TDerived also inherits the methods defined in TBaseA and TBaseB. Suppose you wanted to call the method SetVarB, using a TDerived object. The code for SetVarB is expecting to be passed a pointer to a TBaseB object (all methods are passed a pointer to an appropriate object as an implicit parameter), and refers to fVarB by a fixed offset from that pointer. Therefore, to call SetVarB using a TDerived object, C++ passes a pointer to the middle of the object; specifically it passes a pointer to the part of the object that represents a TBaseB.
This gives you a very basic idea of how C++ implements multiple inheritance. For more details, read “Multiple Inheritance for C++” by Bjarne Stroustrup in Proceedings EUUG Spring 1987 Conference, Helsinki.
So What About HandleObjects?
The next question is how this implementation imposes a restriction on a HandleObject. The answer is simple. Each method of a HandleObject class expects to be passed a handle to the object, instead of a pointer. But when multiple inheritance is used, the compiler sometimes has to pass a pointer to the middle of the object. It is not possible to create a valid handle that refers to the middle of another handle. (Creating a fake handle is a compatibility risk; besides, the pointer into the middle of the handle would be invalid if the handle is moved.)
Designing a new implementation of multiple inheritance that is compatible with a HandleObject, as well as the rest of C++, is a big undertaking. For that reason, it is unlikely that this restriction will disappear in the future. There are, however, two alternatives to consider:
Damn the Fragmentation, Full Speed Ahead
The main reason to use a HandleObject is to reduce the chance of fragmentation that would result from using a non-relocatable block. In a few applications, however, the memory allocation patterns are very predictable, and fragmentation might not be an issue. In those cases, you can use “native” C++ classes. (Don’t use the argument that 8 Mb machines are common, and virtual memory is here to stay so fragmentation isn’t an issue at all. Data always expands to fill the available memory space, real or virtual.)
If you adopt this approach, you should read the article “Using C++ Objects in a Handle-Based World” by Andrew Shebanow in Issue 2 of d e v e l o p, April 1990. This article describes how you can use native C++ objects and minimize heap fragmentation, by overriding the way C++ normally allocates objects. The same techniques can be used to customize the way your program allocates certain objects.
“Doctor, It Hurts When I Do That…”
The other alternative is to give up multiple inheritance. In most cases, this isn’t as difficult as it sounds. The typical way you would do this is with a form of delegation. For example, you could rewrite the class TDerived as:
class TSingleDerived: public TBaseA {
public:
virtual void SetDerivedVar(long newValue);
void SetBaseB(long newValue);
long fDerivedVar;
TBaseB fBaseBPart;
…
};
In this case TSingleDerived inherits only from TBaseA, but includes an instance of TBaseB as an instance variable. It also implements the method SetBaseB to call the method by the same name in the TBaseB class. (In effect, TSingleDerived delegates part of its implementation to TBaseB.) The advantage of this approach is that it requires only single inheritance, yet you can still reuse the implementation of TBaseB.
The disadvantages are that TSingleDerived is not a subtype of TBaseB, which means that an instance of TSingleDerived cannot be used in a situation that requires a TBaseB. Also, TSingleDerived has to define a method that corresponds to each method in TBaseB. (You can, however, define these functions as inline and non-virtual, which eliminates any run-time overhead.)
By The Way…
You should realize that the multiple inheritance implementation previously described costs some extra space, compared to a simpler implementation that does not support multiple inheritance (e.g., the implementation used for a HandleObject). Each vtable is twice as large, and each method call takes about 24 bytes, compared to 14. This is true even if you do not take advantage of multiple inheritance. For this reason, MPW C++ also contains a built in class called SingleObject, whose instances are allocated in the same way as normal C++ instance, but which only supports single inheritance. (By the way, the third class built into MPW C++, PascalObject, uses Object Pascal’s run-time implementation, which takes the least amount of space, but the most execution time.)
Conclusion
You cannot use a HandleObject with multiple inheritance, because of the way multiple inheritance is implemented in MPW C++. Your alternatives are to give up one or the other. You can either use native C++ objects and let the objects fall where they may, or give up multiple inheritance and use a form of delegation.
Further Reference:
• MPW C++ Reference Manual
• “Using C++ Objects in a Handle-Based World,” Andrew Shebanow, d e v e l o p, Issue 2, April 1990.
• “Multiple Inheritance for C++,” Bjarne Stroustrup, Proceedings EUUG Spring 1987 Conference, Helsinki.
Δ HR ˇ ˇˇˇˇ R H ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
HR . ° d ONLN d é Z °Á ( ú Z.PT 28 - Multiple Inheritance and HandleObjects
° d ONLN d / † Z Ø ÷ *Platforms & Tools
° d ONLN d B ª Z « è * Written by: ° d ONLN d N ª ¢ « Û )HLarry Rosenstein ° d ONLN d _ ªfl « ( ƒfl August 1990 ° d ONLN d k ” Z fl ™ ( ‹ ZThis Technical ° d ONLN d z ” ™ fl )P;Note answers a common question about MPW C++: “Why doesn’t ,
Courier ° d ONLN d ∂ fl Z Î Æ ( È Z HandleObject ° d ONLN d ¬ ‡ Æ Ï )T support multiple ° d ONLN d ‘ ‡ Ï )V9inheritance?” It does this by giving a brief overview of ° d ONLN d Ï Z ¯` ( ı Z3how multiple inheritance is implemented in MPW C++. X
° d ONLN dB Z,> *4 What Are HandleObjects Anyway?
° d ONLN da8 ZDt *1MPW C++ contains several extensions to “standard ° d ONLN dí8tD (At C++” for supporting Macintosh ° d ONLN d∞E ZQ (N Z$programming. One such extension is ° d ONLN d‘EQa )¥the built-in class ° d ONLN dÁDaPµ )S HandleObject ° d ONLN dÛEµQ )T. An instance of any ° d ONLN d R Z^ ¬ ([ Zclass descended from ° d ONLN d Q ¬] )h HandleObject ° d ONLN d*R^$ )T is ° d ONLN d.R$^ )4allocated as a handle in the heap. You refer to one ° d ONLN dc^ Zjx (g Z@of these instances as if it were a simple pointer; the compiler ° d ONLN d£^xj (gx#takes care of the extra dereference ° d ONLN d«j Zv/ (s Z/required because the object is really a handle. ° d ONLN d˜É Zè g *A ° d ONLN d˘Ç gé ª )
HandleObject ° d ONLN dÉ ªè3 )T is useful in Macintosh ° d ONLN d É3è )x+programming for the same reason a handle is ° d ONLN dIê ZúÉ (ô Z?useful. The use of handles helps prevent heap fragmentation. ° d ONLN dàêÉú» (ôÉThe nature of ° d ONLN dñè»õ )E HandleObject ° d ONLN d£ú Z®≤ (• ZFimposes some restrictions on how you can use it in a program, however. ° d ONLN dÍ¥ Z¿N *8First, since each instance is allocated as a handle, it ° d ONLN d"¥N¿ )Ù,follows that all instances must be allocated ° d ONLN dO¿ ZÃ" (… Z(on the heap. (“Native” C++ objects can ° d ONLN dw¿"à )»3be allocated on the stack or in the global space as ° d ONLN d´Ã ZÿÔ (’ ZWwell.) Consequently, you always declare variables, parameters, etc. to be pointers to ° d ONLN dÃÔÿ (’Ô
the class. ° d ONLN dÿ Z‰ ò (· Z For example:
° d ONLN d Z˚" *( class TSample: public HandleObject { ° d ONLN dD˙ Z ë *
public: ° d ONLN dP Z á *
… ° d ONLN dZ Z » *
long fData; ° d ONLN dq Z# x *
}; ° d ONLN dx. Z9@ *. TSample *aSampleInstance; // Legal ° d ONLN dß8 ZC¬ *
H TSample anotherSample; // Results in a compile-time error
° d ONLN dN ZZ ¥ *The error message ° d ONLN dN ¥Z )ZMthe compiler generates in this case is “Can’t declare a handle/pascal object: ° d ONLN dPZ Zf‚ (c ZPanotherSample.” At first this message might seem strange, because the last two ° d ONLN d†Z‚f (c‚
lines in this ° d ONLN dÆf Zr¨ (o ZLcode seem to both declare objects. Actually, the first declaration is of a ° d ONLN d˙f¨rÕ (o¨pointer ° d ONLN dfÕr
)! to an object, ° d ONLN df
r )@not ° d ONLN dr Z~ ≤ ({ Zof the object itself. ° d ONLN d*ä Zñ *(The second restriction is that you must ° d ONLN dRäñ )¿4follow the usual rules for manipulating handles. In ° d ONLN dáó Z£õ († Z@particular, you have to be careful about creating pointers to a ° d ONLN d«ñõ¢Ô (†õ HandleObject ° d ONLN d”óÔ£ )T instance ° d ONLN d›£ ZØø (¨ ZMvariable, since the object might move if the heap is compacted. If you write Ω XΩ
*).PT 28 - Multiple Inheritance and HandleObjects (’1 ) of 5 (Î ZPlatforms & Tools ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øä HR ˇ ˇˇˇˇ R H
HR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d H 6 S
*#+ long *x = & (aSampleInstance -> fData);
° d ONLN d , _ 6 k N *then ° d ONLN d 1 ^ N j U )x ° d ONLN d 2 _ U kΩ )L becomes invalid if the object moves. The solution in this case is to lock ° d ONLN d ~ _Ω k¯ ( hΩ
the object if ° d ONLN d å l 6 x È ( u 6(there’s a possibility of the heap being ° d ONLN d ¥ l È xe )≥compacted. Instances of ° d ONLN d Õ ke wπ )| HandleObject ° d ONLN d Ÿ lπ x¯ )T are allocated ° d ONLN d Ë y 6 Ö u ( Ç 6with a call to ° d ONLN d ˜ x u Ñ ª )?
_NewHandle ° d ONLN d y ª Ö Â )F , so you ° d ONLN d
° d ONLN d«ß 6≥ß *LIf you were to look at instances of these classes (see Figure 1), you would ° d ONLN dßß≥¯ (∞ßfind that in each ° d ONLN d%¥ 6¿û (Ω 6Ncase the instance storage would contain four bytes for the C++ virtual table ( ° d ONLN ds≥ûø» (Ωûvtable ° d ONLN dy¥»¿œ )*) ° d ONLN d{¥œ¿¯ )and four ° d ONLN dÑ¿ 6Ãb (… 6=bytes for the instance variable. Any code that accesses the ° d ONLN d¡¿bï (…b instance variable (for example ° d ONLN d‡Ã 6ÿ ü (÷ 6TBaseB::SetVarB ° d ONLN dÔÕ üŸ « )i) would ° d ONLN d˜Õ «Ÿ¯ )(Bdo so using a fixed offset from the start of the object. (In this ° d ONLN d:Ÿ 6Ât (‚ 6Dparticular version of C++, this offset was 0; your offset may vary.) † Ç
*=2 ) of 5 )˛.PT 28 - Multiple Inheritance and HandleObjects +sPlatforms & Tools ˇ¬ HR ˇ ˇˇˇˇ R H
HR , Times
. +Z-Developer Support Center ( -Ë August 1990 / X /
° d ONLN d = Z I ⁄ ( F Z In this case, an instance of ,
Courier ° d ONLN d < ⁄ H )ÄTDerived ° d ONLN d % = Iä )8 has the following layout: † Ç † å
U ˝ Ãx
4 X nu 0 W ˇ pv ° ñ ° ö ˇ˝ † ò
w { w { ° d ONLN dˇˇ +!fVarA † ô † ó 4 p Ñt 0 n ˇ Üv 4 Ü õt 0 Ñ ˇ ùv 4 ù ±t 0 õ ˇ ≥v 4 ≥ »t 0 ± ˇ v ° ñ ° ö ˇ˝ 4 † ò ° d ONLN dˇˇ ( }
vtableDerived † ô † ó ° ñ ° ö ˇ˝ , † ò ° d ONLN dˇˇ +D fDerivedVar † ô † ó 4 ä' óN ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ ( î'fVarB † ô † ó 4 † ≠V ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ ( ™ vtableB † ô † ó † ç † É
HR
° d ONLN d @ ÿ Œ ‰ß ( · Œ$Figure 2–Layout of TDerived Instance ° d ONLN d e Ò Z ˝ ¸ ( ˙ Z This is what you would expect. ° d ONLN d Ö ¸ ¸4 )¢TDerived ° d ONLN d ç Ò4 ˝ì )8 inherits from both ° d ONLN d ° ì ¸Ω )_TBaseA ° d ONLN d ß ÒΩ ˝ÿ )* and ° d ONLN d ¨ ÿ ¸ )TBaseB ° d ONLN d ≤ Ò ˝ )*, and ° d ONLN d ∏ ˛ Z
¬ ( Ztherefore instances of ° d ONLN d œ ˝ ¬ ˙ )hTDerived ° d ONLN d ◊ ˛ ˙
f )8 contain a part that is a ° d ONLN d Ò ˝f ê )lTBaseA ° d ONLN d ˜ ˛ê
ƒ )* and a part ° d ONLN d ˛ƒ
Ó )4
that is a ° d ONLN d
˝Ó )*TBaseB ° d ONLN d ˛
)*. ° d ONLN d Z È ( Z In addition, the virtual table ° d ONLN d5
ÈD )è
vtableDerived ° d ONLN dB D€ )[ includes the tables for both ° d ONLN d`
IE ),TDerived ° d ONLN dˆ>EJú )8 object. The code ° d ONLN d >úJÆ )Wfor ° d ONLN d
=ÆIfl )SetVarB ° d ONLN d>flJ )1
is expecting ° d ONLN d"K ZW ü (T Zto be passed a ° d ONLN d1K üW ⁄ )E
pointer to a ° d ONLN d>J ⁄V );TBaseB ° d ONLN dDKW )*; object (all methods are passed a pointer to an appropriate ° d ONLN dÄX ZdA (a Z0object as an implicit parameter), and refers to ° d ONLN d∞WAcd )ÁfVarB ° d ONLN dµXddÑ )# by a ° d ONLN dªXÑd ) fixed offset from that pointer. ° d ONLN d‹e Zq Æ (n ZTherefore, to call ° d ONLN dÔd Æp fl )TSetVarB ° d ONLN dˆe flq )1 using a ° d ONLN dˇdp? )(TDerived ° d ONLN de?q~ )8
object, C++ ° d ONLN de~q )?!passes a pointer to the middle of ° d ONLN d6r Z~⁄ ({ ZYthe object; specifically it passes a pointer to the part of the object that represents a ° d ONLN dèq⁄} ({⁄TBaseB ° d ONLN dïr~ )*. ° d ONLN dóä ZñÌ (ì ZNThis gives you a very basic idea of how C++ implements multiple inheritance. ° d ONLN dÂäÌñ (ìÌFor more ° d ONLN dÓñ Z¢ Å (ü Z details, ° d ONLN d˜ñ Å¢∫ )'<read “Multiple Inheritance for C++” by Bjarne Stroustrup in ° d ONLN d3ñ∫¢ (ü∫Proceedings EUUG ° d ONLN dD¢ ZÆ Œ (´ ZSpring 1987 Conference ° d ONLN dZ¢ ŒÆ )t , Helsinki.
° d ONLN dfΔ Z’( (“ Z So What About HandleObjects?
° d ONLN dÉ‚ ZÓ à * The next ° d ONLN då‚ àÓƒ ).?question is how this implementation imposes a restriction on a ° d ONLN dÀ·ƒÌ (΃ HandleObject ° d ONLN d◊‚Ó )T. ° d ONLN d⁄Ô Z˚ (¯ Z(The answer is simple. Each method of a ° d ONLN dÓ ˙q )√ HandleObject ° d ONLN dÔq˚¥ )T class expects ° d ONLN d Ô¥˚ )Cto be passed a handle ° d ONLN d3˚ Z h ( Zto ° d ONLN d6˚ h )Vthe object, instead of a pointer. But when multiple inheritance is used, the compiler ° d ONLN dç Z ( Z'sometimes has to pass a pointer to the ° d ONLN d¥ )µ;middle of the object. It is not possible to create a valid ° d ONLN d Z » ( ZMhandle that refers to the middle of another handle. (Creating a fake handle ° d ONLN d=» ( »is a compatibility ° d ONLN dP Z+ (( Zbrisk; besides, the pointer into the middle of the handle would be invalid if the handle is moved.) ° d ONLN d≥7 ZCQ *+Designing a new implementation of multiple ° d ONLN dfi7QC )˜%inheritance that is compatible with a ° d ONLN dC ZO Æ (M Z HandleObject ° d ONLN dD ÆP ∂ )T, ° d ONLN dD ∂P )Ias well as the rest of C++, is a big undertaking. For that reason, it is ° d ONLN d\P Z\ › (Y Z unlikely that this restriction ° d ONLN d{P ›\ )ÉCwill disappear in the future. There are, however, two alternatives ° d ONLN dø\ Zh ë (e Z to consider: ° d ONLN dÃt ZÄQ *(Damn the Fragmentation, Full Speed Ahead ° d ONLN dıç Zô “ *The main reason to use a ° d ONLN då “ò& )x HandleObject ° d ONLN dç&ôñ )T is to reduce the chance ° d ONLN d3çñô )pof fragmentation that would ° d ONLN dOô Z• y (¢ Zresult ° d ONLN dVô y• ) Ofrom using a non-relocatable block. In a few applications, however, the memory ° d ONLN d¶• Z± ã (Æ Z allocation ° d ONLN d±• ã± )1Qpatterns are very predictable, and fragmentation might not be an issue. In those Ω XΩ
(’ Z.PT 28 - Multiple Inheritance and HandleObjects (’3 ) of 5 (Î ZPlatforms & Tools ˇÙ HR ˇ ˇˇˇˇ R H
HR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d < 6 H **cases, you can use “native” C++ classes. ° d ONLN d * < H¯ )–.(Don’t use the argument that 8 Mb machines are ° d ONLN d Y H 6 Tß ( Q 6Ncommon, and virtual memory is here to stay so fragmentation isn’t an issue at ° d ONLN d ß Hß T¯ ( Qßall. Data always ° d ONLN d π T 6 `K ( ] 6=expands to fill the available memory space, real or virtual.) ° d ONLN d ˜ l 6 x8 *8If you adopt this approach, you should read the article ° d ONLN d/ l8 x¯ ( u8$“Using C++ Objects in a Handle-Based ° d ONLN dT x 6 Ñ \ ( Å 6World” ° d ONLN d[ x \ Ñ )&!by Andrew Shebanow in Issue 2 of ° d ONLN d| x ÑK )≤
d e v e l o p ° d ONLN dâ xK ѯ )=%, April 1990. This article describes ° d ONLN dØ Ñ 6 ê ¡ ( ç 6how you can use native C++ ° d ONLN d Ñ ¡ ê¯ )ã>objects and minimize heap fragmentation, by overriding the way ° d ONLN d ê 6 ú œ ( ô 6 C++ normally allocates objects. ° d ONLN d) ê œ ú¯ )ô: The same techniques can be used to customize the way your ° d ONLN dd ú 6 ® ” ( • 6"program allocates certain objects. ° d ONLN dá ¥ 6 ¿ *"“Doctor, It Hurts When I Do That…” ° d ONLN d™ à 6 ÿ‰ *bThe other alternative is to give up multiple inheritance. In most cases, this isn’t as difficult ° d ONLN d É ÿ¯ ( ’‰as it ° d ONLN d ÿ 6 ‰ w ( · 6
sounds. The ° d ONLN d ÿ w ‰¯ )AMtypical way you would do this is with a form of delegation. For example, you ° d ONLN dm  6 Ò ¢ ( Ó 6could rewrite the class ,
Courier ° d ONLN dÖ ‰ ¢ ⁄ )lTDerived ° d ONLN dç Â ⁄ Ò Í )8 as:
° d ONLN dí ˝ 6 ( 6) class TSingleDerived: public TBaseA { ° d ONLN dº 6 m *
/ void SetBaseB(long newValue); ° d ONLN d-% 60 Â *
# long fDerivedVar; ° d ONLN dQ/ 6: ‡ *
" TBaseB fBaseBPart; ° d ONLN dt9 6D c *
… ° d ONLN d~C 6N T *
};
° d ONLN dÖZ 6f t *
In this case ° d ONLN díY te ÷ )>TSingleDerived ° d ONLN d†Z ÷f )b
inherits ° d ONLN d™Zf; )-
only from ° d ONLN d¥Y;ee )8TBaseA ° d ONLN d∫Zef¯ )* , but includes an instance of ° d ONLN dÿf 6r ` (p 6TBaseB ° d ONLN dfig `sf )*9 as an instance variable. It also implements the method ° d ONLN dffrû (pfSetBaseB ° d ONLN d gûs¯ )8 to call the method ° d ONLN d3t 6Ä E (} 6by ° d ONLN d6t EÄ Ø )the same name in the ° d ONLN dKs Ø Ÿ )jTBaseB ° d ONLN dQt ŸÄ4 )* class. (In effect, ° d ONLN dfs4ñ )[TSingleDerived ° d ONLN dttñį )b delegates part of its ° d ONLN dãÅ 6ç è (ä 6implementation to ° d ONLN dùÄ èå π )YTBaseB ° d ONLN d£Å πç … )*.) ° d ONLN dßÅ …ç¯ )>The advantage of this approach is that it requires only single ° d ONLN dÊé 6öB (ó 6;inheritance, yet you can still reuse the implementation of ° d ONLN d!çBôl (óBTBaseB ° d ONLN d'élöp )*. ° d ONLN d)ß 6≥ µ (∞ 6The disadvantages are that ° d ONLN dD¶ µ≤ )TSingleDerived ° d ONLN dRß≥t )b is not a subtype of ° d ONLN dg¶t≤û )]TBaseB ° d ONLN dmßû≥≈ )*, which ° d ONLN duß≈≥¯ )'
means that ° d ONLN dÄ¥ 6¿ Ä (Ω 6an instance of ° d ONLN dè≥ Äø ‚ )JTSingleDerived ° d ONLN dù¥ ‚¿N )b cannot be used in a ° d ONLN d≤¥N¿ )lsituation that requires a ° d ONLN dÃ≥ øÙ )|TBaseB ° d ONLN d“¥Ù¿¯ )*. ° d ONLN d’¡ 6Õ V ( 6Also, ° d ONLN d€¿ Và ∏ ) TSingleDerived ° d ONLN dÈ¡ ∏Õ¯ )b: has to define a method that corresponds to each method in ° d ONLN d$Õ 6Ÿ ` (◊ 6TBaseB ° d ONLN d*Œ `⁄ ® )*
. (You can, ° d ONLN d7Œ ®⁄¯ )H@however, define these functions as inline and non-virtual, which ° d ONLN dx⁄ 6Ê ⁄ („ 6"eliminates any run-time overhead.) ° d ONLN dõÚ 6˛ â * By The Way… ° d ONLN dß
6 ó *You should realize ° d ONLN d∫
ó¯ )aGthat the multiple inheritance implementation previously described costs ° d ONLN d 6"
( 6(some extra space, compared to a simpler ° d ONLN d*
"¯ )◊-implementation that does not support multiple ° d ONLN dX# 6/ (, 61inheritance (e.g., the implementation used for a ° d ONLN dâ".l )‚ HandleObject ° d ONLN dï#l/ó )T ). Each ° d ONLN dû"ó.¡ )+vtable ° d ONLN d§#¡/¯ )* is twice as ° d ONLN d±/ 6;Q (8 6;large, and each method call takes about 24 bytes, compared ° d ONLN dÏ/Q;¯ (8Q#to 14. This is true even if you do ° d ONLN d ; 6GQ (D 6>not take advantage of multiple inheritance. For this reason, ° d ONLN d N;QG¯ (DQ MPW C++ also contains a built in ° d ONLN d oH 6T P (Q 6class ° d ONLN d uH PT o )called ° d ONLN d |G oS √ ) SingleObject ° d ONLN d àH √T¯ )T=, whose instances are allocated in the same way as normal C++ ° d ONLN d ΔT 6`e (] 6?instance, but which only supports single inheritance. (By the ° d ONLN d
Te`¯ (]e way, the third class built into ° d ONLN d
%a 6m r (j 6 MPW C++, ° d ONLN d
.` rl Δ )< PascalObject ° d ONLN d
:a Δm )T, uses Object ° d ONLN d
Ham¯ )@1Pascal’s run-time implementation, which takes the ° d ONLN d
zm 6y+ (v 64least amount of space, but the most execution time.) Ω 4Ω˘
*_4 ) of 5 )˛.PT 28 - Multiple Inheritance and HandleObjects +sPlatforms & Tools ˇx HR ˇ ˇˇˇˇ R H
HR , Times
. +Z-Developer Support Center ( -Ë August 1990 / X /
• ° d ONLN d^ ≈ ~ — )MPW C++ Reference Manual ° d ONLN dw — l › p ( ⁄ l• ° d ONLN dy — ~ › ˚ )“Using C++ Objects in a ° d ONLN dë — ˚ ›’ )}&Handle-Based World,” Andrew Shebanow, ° d ONLN d∑ —’ › )⁄
d e v e l o p ° d ONLN dƒ — › )C, ° d ONLN dΔ › ~ È fi ( Ê ~Issue 2, April 1990. ° d ONLN d€ È l ı p ( Ú l• ° d ONLN d› È ~ ı> )'“Multiple Inheritance for C++,” Bjarne ° d ONLN d È> ıy )¿ Stroustrup, ° d ONLN d Èy ı ); Proceedings EUUG Spring 1987 ° d ONLN d- ı ~ ¥ ( ˛ ~
Conference ° d ONLN d7 ı ¥ Á )6 , Helsinki. Ω XΩ
(’ Z.PT 28 - Multiple Inheritance and HandleObjects (’5 ) of 5 (Î ZPlatforms & Tools ˇ
